[MUD-Dev] Re[2]: [MUD-Dev] Text Parsing

[Travis Casey]

On Monday, May 31, 1999, Kylotan wrote:

> Sure, but they were still a lot more functional than most Diku variants,
> from my own experiences. I remember that The Hobbit (by Melbourne House, I
> think) copes admirably with adverbs, prepositions and so on. This ran in
> 64k with some basic graphics code also competing for space. It did have
> fewer verbs/commands than most muds, which may be an important factor. And
> I understand that some of that code might have been calls to firmware
> routines, etc. But it's still very small, relatively.

Part of it has to do with the universe size.  The typical such
adventure game had perhaps thirty or forty different objects to deal
with, a similar number of verbs, and had no user extensibility.  Thus,
the game's creator could make a lot of assumptions about what people
would be likely to do, make lists of all the adjectives which could apply
to a particular object, etc.  Also, the game was often structured in a
way such that particular verbs or objects would only have to be dealt
with during particular parts of the game -- thus, overlay techniques
could be used, modifying the parser to deal with the objects currently
of interest.

Object structures were often simpler -- for example, there might be
only one or two container-type objects in the entire game, which
allows avoiding problems with nested containers and the like, and also
made them more amenable to custom coding, or to using tricks like a
routine for handling a table that's hard-coded into the room itself.

On a modern mud, there are hundreds or thousands of different objects,
many of which are added by builders and which the original coders may
never have conceived of having added to the mud.  Since there are many
users, there's no guarantee that a particular object can't be brought
into play at a particular time -- so overlay techniques aren't as
useful.  And, of course, there may be more complex object types and
object relationships.

Lastly, user expectations were often lower.  The Infocom games were
exceptions -- a lot of the games of the time used simple two-word
verb-noun "parsers".

> Well, I would have thought that something that used to execute within half
> a second on a Z80 CPU would not be a problem, performance-wise. But then,
> if I fully understood what was going on here, I wouldn't need to be asking
> :)  I expect, however, that the code in modern interactive-fiction engines
> such as Inform or Tads has a lot more code than is needed for a parser of
> the complexity I am talking about.

Remember, though, that that Z80 was only having to handle one player,
that most such games had only one or two things that could take
independent action, they generally had extremely simple combat
systems, and that they had only a couple dozen objects to check things
against.  It's not hard to have fast execution times when your game is
doing so little, relative to what modern muds do.

--
       |\      _,,,---,,_        Travis S. Casey  <efindel at io.com>
 ZZzz  /,`.-'`'    -.  ;-;;,_   No one agrees with me.  Not even me.
      |,4-  ) )-,_..;\ (  `'-'
     '---''(_/--'  `-'\_)




_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev