[MUD-Dev] Naming and Directories?

Mik Clarke mikclrk at ibm.net
Tue Mar 16 21:40:42 New Zealand Daylight Time 1999


Chris Gray wrote:

> [Mik Clarke:]
>
>  >Given a task of sending a message to a specific player, when that player could be
>  >located anywhere within the mud, how do you propose to do it faster than by running
>  >the list of all connected players?  Sure, a binary index by name might help, but I
>  >suspect you'd have trouble seeing the saving...
>
> Depends on how often you do it. After removing some idiocy in my database
> code, and skipping the MUD language interpreter, the biggest hits on
> my profiling of a test with 600 "machines" was the code that sees who
> should get a message whenever a machine does something. E.g., a machine
> goes from one room to another. All characters and machines in both
> rooms may need to know about that. So, with 600 machines moving around
> every couple of seconds, thats an order 600 * 600 = 360,000 cost. It
> starts to be noticeable. So, the bit of work I've done recently has
> been to start adding more pointers to the agent structures, so that
> I can link them together based on location, and also via a table
> hashed by locations. The first ring gets me those in the old location.
> The hashing gets me to any ring for the new location. I expect a
> noticeable speedup once I get all the pointer fiddling right.

Ever heard of event driven interaction?

In a Diku each room has a list of all of the objects and all of the players that are in
the room.  The thing to do, as you are finding, is to utilize this 'locality' to reduce
the amount of work you have to so.

The way CthulhuMud handles this is as follows:

1. A context is created.  This describes the participants and their roles (actor, victim,
observer (yes, it changes for each observer), primary object, secondary object, number,
text and room).
2. An event is created this references the context and has a description of both the type
of action and a more specific subtype.  Examples might be GET and GET_ITEM or DEPART and
DEPART_WALK.  Further details of the action are stored in the context.  The context also
contains pointers to the templates for the messages that the actor, the victim and any
observes get to see.
3. The event is issued to the room (as this is C it just a function call with the room
and the wev as its arguments).
4. The room then passes to event to each mob in the room (who might be interested in it).

5. Code for the mob then decides what to do with it.  For player Mobs, the message is
sent to the player.  For NPC mobs it can trigger mobprogs.

There are a couple of refinements:

Challange events.
The event is issued as a challange before the event occurs. Mobs may veto the action by
triggering a mob prog.  This prevents the action from happening, but it is up to the mob
to explain why.  (The best traditional mobprogs can do is to say 'Naughty player, put
that down right now!' and maybe force them to drop it.)

Scrying and Monitoring
If everything that happens in the room is described by an event (and CthulhuMud is about
75% of the way there), then its possible to extend the room_issue_wev function to send
the event to mobs which are elsewhere but which want to monitor the room (for cool
animation effects) and to feed them to objects that are 'remotely observing' the room.
(Scrying isn't yet implemented, but I've got all the bits.)

Echos
If you define exits to be 'transparent' 9to light, sound or both) you can punt the event
into neighbouring rooms, allowing people to see further in open spaces.

Mik



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




More information about the MUD-Dev mailing list