[MUD-Dev] Flow of messages

Travis Casey efindel at earthlink.net
Thu May 8 11:00:51 New Zealand Standard Time 2003


Friday, May 02, 2003, 10:21:50 AM, sanxion sanxion wrote:

> I have been pondering upon the flow of messages that are handled
> on the server when something occurs. Lets say a player gives
> another player items. This generates a bunch of information for
> example:

>   1. Text relevant to all players in the room:
>      Player X1 gives Y to Player X2.
>      Etc.

>   2. Text relevant to the giver:
>      Player X2’s hands are full.

>   3. Text relevant to the receiver:
>      Player X1 tries to give you Y, but your hands are full.

>   4. Events sent to npc:s:
>      Event(Player X1, give, Y, Player X2)

> Up to now I have used a model that resembles sending e-mail. I set
> a 1) content-type, 2) content, and 3) add a number of
> receivers. Receivers can be clients, npc:s, special scripts, or
> loggers. Content-types can be text or events. Each receiver parses
> the message in the way they were designed to. A npc might perform
> an action, loggers would log text to a file, a client send a
> message to the buffer etc. etc.

> I have come to the understanding that most muds process messages
> in the same function/method. This seems fairly inflexible to
> me. Anyone agree or disagree? Is the model I’m using something to
> extend upon or are there better solutions? Perhaps someone could
> give me a breakdown of what they use and if I’m out hiking?

There's two different things involved here, really:

  1 - Getting messages to objects.

  2 - Deciding what messages to send to which objects.

Most muds have basic message functions which handle #1, and it
sounds like you do too.  On #2, many muds simply leave that up to
the programmer to accomplish -- but there are some which have
functions to handle common cases for the programmer.

For example, the Lima mudlib provides several things for this.  If
I'm remember right (it's bee a few years), it has:

  1 - a character does an action which everyone in the same room can
  see.  Optionally, the action may have a target.

  2 - a character does an action which only the character and a
  specific list of recipients can see.  Optionally, the action may
  have a target.

  3 - a character does a targetted action which only the character
  and the target can see

    (IIRC, #3 is just a "wrapper function" which calls #2 and is
    provided for convenience, since #2 could always be used where #3
    is used.)

Further, these functions take a string which has variables in it,
and objects are supplied to match the variables.  There's also some
special marking to indicate verbs which may need to change.  A
parser figures out what message should be sent to whom, and sends
it.

An example will probably help:

 "$N $vattack $t.", attacker, target

 send this with the "everyone in the room can see" function, with the
 attacker being Buffy and the target Boffo.
 
 Buffy sees:  You attack Boffo.

 Boffo sees:  Buffy attacks you.

 everyone else in the room sees:  Buffy attacks Boffo.

There are also variables which can be used to generate appropriate
pronouns for an object, depending on gender, and to generate the
correct indefinite article for an object ("a" or "an").

Lima doesn't do the thing for NPCs which you mention, but I don't
think it would be too terribly hard to add.

--
Travis Casey
efindel at earthlink.net


_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev



More information about the MUD-Dev mailing list