NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/rec/arts/intfict/939

Internet Message Format | 1992-11-22 | 3.5 KB

Xref: sparky rec.arts.int-fiction:939 rec.games.int-fiction:931
Newsgroups: rec.arts.int-fiction,rec.games.int-fiction
Path: sparky!uunet!think.com!ames!pasteur!cory.Berkeley.EDU!librik
From: [e-mail] (David Librik)
Subject: Slow noun resolution in TADS
Message-ID: <[e-mail]>
Keywords: tads slow noun resolution
Sender: [e-mail] (NNTP Poster)
Nntp-Posting-Host: cory.berkeley.edu
Organization: University of California, at Berkeley
Date: Mon, 23 Nov 1992 05:56:59 GMT
Lines: 61

I dropped Mike Roberts, the author of TADS, a note about the problem
that it takes a long time to deal with a "door" if there are a lot of
"doors" in the game.  He sent this back to me: thought you would find
it interesting if you are using TADS.  (I don't like either of his
solutions -- I wish I had more control over the parser.  I'd like to
be able to say, for specific words, how they should be matched.  But
certainly the "create a floating object" method would work fine for
a lot of doors -- you just keep track of their open/closed states yourself.)

- David Librik
[e-mail]

-------------------------------------------------------------------------

  Unfortunately, the slow door problem is still in 2.0, since the
parser is largely unchanged.  The problem is that the parser starts
off by finding every object that answers to the indicated name, then
calls <verb>.validDo for each one.  When you have twenty or thirty
objects matching a name, it ends up calling a lot of validDo methods
before it decides which objects should even be considered.
  I've considered changing things so that it goes the other way - the
verb would produce a list of objects that are acceptable, and the
parser would run through that list looking for words that match.  This
would definitely speed things up (a lot) in these situations where you
have a lot of objects with the same name, but it would probably slow
things down (a little) most of the time.  It might be a reasonable
trade-off.
  There are a couple of workarounds.  The easiest is obviously to cut
down on the number of "noise" objects that use the same name.  Another
is to choose slightly different objects; in "Deep Space Drifter", we
intentionally had to start inventing new types of controls when we found
that we had too many damn buttons; so we started using switches, levers,
touch pads, and so forth.
  However, if you really need to have tons of objects with the same
name, there's a hack that lets you deal with it - especially when the
objects are basically noise.  What you do is create an object with
a non-fixed location; it shows up in any room that's appropriate,
based on the player's current location.  For example, in Deep Space
Drifter, the sixty-four swamp plants are all a single object with
a location property defined like this:

    location =
    {
      if (Me.location.isSwampRoom) return(Me.location);
      else return(nil);
    }

The swamp plant doesn't really exist anywhere, but it will always
look like it's in the same location as the player whenever the player
is in a swamp room.
  The same thing could be done with doors:  just define a property of
each room that contains a door and check that.  Of course, this wouldn't
work if the objects had to be different; however, if many are identical
with a few different, you could use this trick with the identical ones
to cut down on the disambiguation time.

--Mike

PS - feel free to post this note or a summary in r.a.i-f, if it would
add to the discussion there.