[MUD-Dev] Re: clients anyone?...

[Adam Wiggins]

On Tue, 11 Aug 1998, Hans-Henrik Staerfeldt wrote:
> On Tue, 11 Aug 1998, Adam J. Thornton wrote:
> If you want complex scripting, it would be a good idea to extend the
> protocol to handle pre-processed data. In reality, your in-game model
> of the world is translated into nasty ambigous text for reading of humans,
> or even worse - graphics. Unless you want to do some very nasty AI attempt
> at understaning the messages (graphics!) intended for the player you 
> should extend your good flexible protocol with an AI stream mode that 
> allows for nicely formatted events to be parsed to the remote NPC.
> 
> Player> Buffy pick up the hammer.
> AI> Pickup((Player 52364),(Object 23647)).
> 
> or something to that affect.

Absolutely.  This is, I think, a pretty fundamental part of any highly
extensible game world.  I usually refer to them as "events", although this
can be somewhat confusing as it overlaps somewhat, but not completely,
with the traditional notion of events as a device in the code.

On your typical codebase this is handled by the very simple:

  Player->Send("%n smile%s happily.");

Problems with this are numerous.  First is, of course, the lack of any
context.  Some implementations try to add extra parameters to help account
for this deficiency, like so:

  Player->Send(SEND_TO_ROOM, VISION, "%n smile%s happily.");

or possibly extra parameters in the markup language:

  Player->Send("<Radius=10m><VisionRequired=75>%n smiles%s happily.");

This can work, but as you mention above, doesn't help out our poor NPC AIs
much, plus it's at the whim of the person creating the message to include
all the relevant parameters, which can turn into a mess if there's a lot
of them.  Simple things like some sort of priority level (so that you can
cull out someone smiling in the midst of a chaotic battle sending tons of
messages), concatination rules (so that you can do "Bob smiles, and draws
his sword.").  Check the archives for posts from Nathan for more examples
in this vein.

The solution that Orion and I can up with is actually having a fixed list
of events that can occur.  A potential downside is that you make it
difficult to add new messages, since you can't just toss out a one-liner;
however, we actually saw this as a good thing.

An event has several standard parameters.  A type (EVENT_PICKUP, in the
example dicussed above), actors and direct objects, and extra parameters
such as intensity.  The type array itself actually encodes data like what
sense(s) you need to detect the event.
The message itself is not a simple string like "%n picks up %o"; there was
usually a number of phrasings to keep it from getting too repetative
("get", "take", "pick up", for a simple example) as well as special
phrasings for extra parameters ("snatches", "grabs", "carefully picks up")
and parameters for where each message would fit into a sentence, so that
we can arrange multiple messages properly.

Getting it to display on the screen properly is a bit tricky, but mostly
just coding the various special cases (which English is full of).

The *good* part about all this, besides output which doesn't look quite so
canned, is the ease of manipulating the events once they are encoded this
way.  Someone using the event (ie, EVENT_MUSHROOM_CLOUD for the 'nuclear
blast' spell) doesn't have to worry about the targets of the event, what
senses they have, or anything else.  They just launch the message.  From
there, various entities receive the event.  If the entity is player
controlled, the event is put on a queue to be concatinated with other
messages and finally sent to the player.  If the the entity is AI
controlled, the event is sent to the AI and it can deal with it how it
likes, without having to worry about checking "am I blind?" "am I deaf?"
"am I close enough to hear this?" "is the door between me and the person
that sent the even closed?" special cases.

These are also the same events which are then stored in the NPCs' memory.
I've posted a few times on this part of the functionality, which is a
whole other can of worms (and requires an event type heirarchy, so that
multiple events that are similar but not identical can be grouped
together).  However the benefits of this are obvious immediately - instead
of storing a string like "Bubba gets the sword" which has to be parsed
over and over again, the NPC stores specific information (local id's for
Bubba and the sword, so that it can associate the event with other events
involving the same people and things) as well as a single word for the
event id (EVENT_PICKUP).

Adam