[MUD-Dev] Languages

Chris Gray cg at ami-cg.GraySage.Edmonton.AB.CA
Sun May 25 10:26:53 CEST 1997


[Miro:]

:[actor] {switch value=[sense:magic]:[range:1..5]mumbles something,
:pointing a finger toward[default]casts magic missile at} [victim].
:
:Note about syntax: Everything in []'s is evaluated before the message
:starts to propagate (in this case, actor and victim). {}'s are
:evaluated when they reach the players, and in some cases evaluation
:of []'s inside is delayed.
:
:The idea is that everybody in the room will interpret the event
:accorting to their ability to sense magic. {switch} will automatically
:delay the evaluation of [sense] until the message reaches the actual
:player, and then will figure up the strength with which player can
:detect particular information in the message (magic, in this case.
:[sense] mechanism isn't yet cast in stone and is very easy to
:extend). If an observer isn't very sensitive to magic, he will only
:see what the caster does with his arms and mouth, otherwise he
:gets the complete information.

OK, thanks. I'm on track with the discussion now.

:Now if this message propagates to another room, or to the realm object,
:all sense values get lowered, so players looking at the event from
:afar have much lower chance to recognize the spell. I have no idea
:how it could be done with prints, short of writing 20-50 lines of
:code each time you need to print a context sensitive message that
:can reach a large number of players.

Doing this other ways would be more work for the coders, yep. But still
doable, however. In AmigaMUD I have a builtin 'ForEachAgent' which will
execute some code for each agent in a given location. I would set up
some variables (Ick!) recording what is going on, then use it to decide
what to do for each such agent. It is at that point that the sense
abilities would be evaluated. The result would be a single string going
out to each player, and perhaps to NPC trigger entries. Propagation to
other rooms would be just looping through the exits from the current
room (graph traversal stuff). So, instead of your hyperstring, the coder
would have to call a couple of scenario routines, passing things like
the magic "loudness" of the event, and the special and default strings.
Very procedure oriented, rather than data oriented. :-)

:Oh, for efficiency this is internally compiled to pretty weird
:format (basically a tree of strings and lightweight objects),
:and decompiled/pretty-printed whenever a player wants to edit it.

OK, I could do that too, then evaluate the structure for each agent. In my
case it would require something other than a list of dissimilar entities,
but that's no big deal. (Bringing us back to what I recall as being the
original subject here.) Actually, if I really wanted to get kinky, I could
take the pieces of the event, and dynamically generate procs for each
such piece. Then, I could just use a list of procs to pass around. Each
agent would simply run through the list and call each one. Might be a
reasonable way to go if it gets complicated enough, but there is extra
overhead involved in creating all those procs!

--
Chris Gray   cg at ami-cg.GraySage.Edmonton.AB.CA



More information about the mud-dev-archive mailing list