[snip]

The main difference in most interpreters is the sophistication of the
adventure you can create solely from data files, without having to write
any script.  While this interpreter is more advanced than some, e.g. in
the sophisticated 'container object' implementation, and the multi-level
hints, you'll still end up writing more or less the same amount of code
that you would in any other system.  There's no 'magic wand' a non-
programmer can wave to instantly create a complicated adventure, I'm
afraid. :-(

This is just one reason why the sequel to Quicksand (It's No Game) still
exists as nothing more than loose, and fairly incoherent notes on my system.
I have some good ideas for the game, but haven't had the time to tie them
together in a way that will enable me to start the [extra] mapping process.

The closest you can probably get to that is to provide a very simple script
into which the user can drop his own objects/rooms descriptions (this is
easily achievable with Trellis) - but then, there'd be nothing particularly
special about the result.

I haven't had time to play with BAABE yet - or more specifically, play your
conversion of Pyramid. How faithful a conversion is it?

Andrew

Without a doubt, the only complicated code required is that in the
interpreter.  Most of the script is simple, and even repetitive; an
average line goes, "If the player hasn't done this yet, don't let him do
that".  The main limiting factor is being bothered to cover all
eventualities.  I'm still not sure quite what you mean by 'flags', but
as the flags you'll be using will be BASIC variables of your choice of
name, it can't be that difficult to keep track of them.

For the record, I definitely agree with what Vince says about writing
the fiction part; once you know what you're doing, it's fairly easy, but
you'll have to go to some considerable cognitive effort to work out how
you want your adventure to play.

'Variables to hold all the data': Sort of.  All game-relevant ones are
taken care of for you; the variables you have to worry about are the
'flags' above.

'Indexes for location, inventory, etc.': Either this is much more
complicated than it sounds, or you're still hoping for a 'magic wand'
solution.

Andrew

Dialogue with game characters will still have to be implemented on the
script side, but it's a good idea to limit that anyway since it's very
confusing for players to try and work out what needs to be said.
Standard practice is to define a set of dummy noun keywords and check to
see if the player uttered any of them.

It's only when I see the length of the interpreter code that I realise
the benefits to be gained by not having to write or adapt it every time
I wanted to write a new game!

If you mean fleshing out the descriptions and text, then, yes, fair enough -
changing "A blue room with a table and chair in the middle" to "This room
has light blue walls. The floor is a darker blue, but the bright light in
the middle of the ceiling blinds your view of that, so its particular shade
is harder to determine. There is a small kitchen table in the middle of the
room, with a single chair in front of it." I can accept and agree with.

But if that fleshing out you do _really_ mean the story itself, then "Ugh!"

Modifying it where necessary to fit with unforseen limitations in your
development system - or abilities - is also acceptable (due to necessity).
Or even to mactch your available resources, which I had to do with the final
part of Quicksand; I just couldn't get a photograph to match my original
ideas. But not fleshing out the story. That's making it up as you go along,
and can lead to a weaker, less coherent story.

Forgetting what I've said in that quoted paragraph, which was me thinking
about possibilities for a rewrite that will in all likelihood never happen,
and looking at the existing version of Trellis, and taking objects as the
example:

In Trellis, each object has a variable associated with it which is its
location. If the player has picked an object up, that location is zero. If
it's out of play, you can set it to be in a room that doesn't exist. (I tend
to use -1 which is more obvious, and you could of course consider using
_specific_ numbers for specific things; up to you - but again, that's
delving into special cases, which may or may not be necessary).

When you enter a room and your script loops to the point where the
description of the room must be given, Trellis deals with which objects can
be seen there by looking at that variable for each object and determining if
its room number is the one the player is in. (Having not yet looked, I don't
know if that's how Martin has gone about it). So, at the very simplest, your
object handling is to supply Trellis with a list of objects and their
properties - unless you want to intervene with how it handles a particular
object (to make it fit with your puzzles), Trellis will cope with seeing the
object, describing it, picking it up, dropping it, etc with no other effort
from you.

So, instead of writing some source code which basically says:

* Look up the description for room 43 and print it.
* Look up the exits for room 43 and print which ways the player can go.
* Look through the objects and see which ones are in room 43, printing
  their short description.

(but which would be a bit more involved than that) you can instead just
issue a script command (or a small set of them) to do _all_ of that. Your
task as the adventure writer becomes much more simplified.

I think in one of your other posts, you've mentioned using a flag to
indicate whether the player can take a particular object. The way I handled
that in Trellis is to assign each object a weight, and a maximum weight the
player can pick up. That means the system can automatically handle cases of
the player only being able to lift the sack of potatoes if he isn't already
carrying the bag of cement - all you have to do is set these figures
correctly at the start. If you just want a simpler "can or can't pick up",
set the weight of everything he can pick up at zero, set his max to one, and
set the weight of anything you want seen as an object, but which the player
can't take, to two. I use bigger numbers for the max and the weight of
'fixed' objects, to make it more obvious - but as long as the latter are
bigger than the max, Bob's your uncle. You don't have to worry about
handling these things - just about setting the values correctly in the
Object definitions file.

The whole point is so that you can devote considerably more time to the
fiction itself, and how it plays out, and let an already existing system
handle much of the standard work. This is, in fact, not unlike how we go
about developing things in general anyway - rather than keep writing the
same bits of source code over and over again, we re-use it by putting it in
a library, which our programs call; think of a good adventure development
system along those lines: It's a programming library for the adventure
writer.

[big snip]

When I converted Pyramid, I was determined that it should be as faithful
a conversion as possible - even including original bugs if necessary.
(I seem to remember, for example, that the only two valid synonyms for
the graffiti were 'TEXT' and 'WRIT', which always puzzled me!)  For this
reason, I actually wrote a BASIC program to convert Trellis data files
into BAABE ones - I could let you have it if you like, although it
probably isn't much use for anything else, especially since BAABE
doesn't have a 'weight' system and so it simply treated weight 200 as
the equivalent of the 'do not pick up' flag.  Also, considerably more
work was required to re-implement the script in 'library' rather than
'!RunImage' form - see below.

While writing the converter, I realised there were several ways in which
BAABE differed from Trellis in the most fundemental aspects of its
rationale. To take just one example, you wondered whether I had gone
about object lists in room descriptions the same way you had; no, I
haven't.  In fact, BAABE's system is the complete opposite.  Rather keep
track of which nouns are in which rooms, it keeps track of which rooms
contain which nouns.  I find this considerably simplifies things in
matters of room descriptions, since you only have to read out one list,
rather than scan the entire noun database.  A disadvantage would be that
you can't just easily check to see which room a noun's in, but I find
that, in most circumstances, if you want to do this you already know
which room it should be in and you can use the function (FNhere)
provided for that purpose.

Another thing you mentioned above is that Trellis is fundementally a
library for an interpreted script file.  BAABE, on the other hand, is an
engine of which certain aspects may be readily customised, by means of
filters and handlers the interpreter calls when necessary.

I'm not saying either approach is necessarily better than the other,
except perhaps that my approach doesn't necessitate the writing of an
entire language specification and, under most circumstances, is less
work for the programmer, but that Trellis is more customisable in
certain fundemental aspects (duplicating the eight turns of darkness
- suppressed descriptions - was a nightmare!).

[...]

The way the "WORDS" is that the first word on the line is the keyword that
is used in the script for recognising what the player has entered, with the
rest on each line being seen as synonyms for that word.

So for a line in the words file that reads:

TEXT WRIT

What *should* happen is that if, in the script, there's a line:

IF FNSaid("TEXT") THEN blah-blah-blah

(The actual condition would also check for READ, obviously, but...)

The FNSaid function in Trellis itself should find the line in the words file
that begins with "TEXT" and then use INSTR to check for each item on that
line in the player's input string. "READ WRITING" contains "WRIT" so that
should match. "READ WHAT'S WRITTEN" should also work (which is why I used
"WRIT" instead of "WRITING"), etc.

But if that *didn't* work, then I guess the rest of the first sentence after
"unless" is probably the case. i.e. I did something really stupid at some
point which stopped it working. I probably "fixed" something else. :)

<fires up the Iyonix, in much the same way that Gene Hunt fires up the
Quattro. Or not.>

A quick glance at the words and script files and everything /seems/ fine.
The actual line is:

IF (FNSaid("READ") OR FNSaid("EXAMINE")) AND FNSaid("TEXT") AND Store%(3)=10
THEN

Store%(3) is the player location - 10 being the room with the writing. That
part of the condition is ensuring you can only read the writing if you can
see it - ie if you're there. By checking for (READ OR EXAMINE) AND TEXT
means you should be able to READ or EXAMINE the words.

Rather than play it through (again!), I've just added "WRIT," as a synonym
to "PEDESTAL" in the Words file, and built the modified game. (The pedestal
appears in the opening room). Typing "EXAMINE WRITING" now serves to examine
the pedestal - this suggests that the FNSaid function is working correctly.
(Well, in the latest build of Trellis, anyway - the one used for Quicksand.
OTTOMH, I don't think any changes were made to that area in the program -
mainly it was to do with screen modes and graphics, etc).