[DGD] Hooks

Noah Gibbs noah_gibbs at yahoo.com
Mon Sep 15 20:02:18 CEST 2003


--- alderamin at jippii.fi wrote:
> Okay here's an example of the problem I've been
> trying to solve: say, we 
> have a "living" class which has a method
> "receive_damage". Then a wizard 
> wants to make a guild power or an item which does
> something funky to the 
> damage.

  Got it.  Yeah, you'll want to either have the item
send a signal (or whatever the Kernel Library calls
'em...  I forget), or do something similar yourself. 
So basically, you'd make every DGD object that wants
to modify how damage is given or received subscribe to
some appropriate subset of the receive_damage signal. 
You'll probably want to write this signal stuff for
yourself, since you'll probably want items to be able
to subscribe to subsets like "ice_damage" or
"damage_to(PLR_BOB_7)" or
"damage_from_item(EVIL_SWORD)".  Not that you'll
represent them as strings like that, but you know what
I mean.
  But if you write it yourself and keep track of stuff
like that, you can avoid sending signals to every item
and its brother by keeping separate lists for, for
instance, ice damage, or damage to a given player, or
damage done by a particular item.  At first you can
just use one big uberlist and a lot of if statements,
then as it starts to get slow and bog down, make more
lists.  That'll save you time and cost you RAM, which
is the right tradeoff as your MUD gets bigger.

> Or the player can "wield" or "wear" stuff
> and some special items 
> want to know when they're wielded or worn so they
> can do something. 
> Anyway, things which were done with shadows in the
> dark ages.. =)

  Again, you'll want to add "weild" and "wear"
signals.  In this case, I doubt you'll need a lot of
separate lists, though I guess you could do lists by
player.  But weilding and wearing happens seldom
enough (assuming it'll only occur in response to
something a player actually types) that you can make
this really inefficient.  I mean, as long as it takes
less than a fiftieth of a second, you don't care,
right?  And a fiftieth of a second is a *lot* of
computation these days.

  That would change if, for instance, you had monsters
fight each other regularly and they frequently
disarmed each other.  Then you'd want to keep a
wear/wield signal list for every NPC, or at least for
every region or something.  However, few MUDs do this,
so I wouldn't bother to optimize for it at first.

> I thought there could be some kind of message
> system, like when a player 
> wields a weapon it would send a message like
> "Moomin, wield, 
> evil_sword", now this evil_sword could be listening
> to messages where 
> it's involved and see that Moomin wields it and do
> something evil :P ..

  Yup.  Again, I'd build your own.  That lets you
optimize for the cases you actually use.  I'd *also*
keep a log of what signals get sent so that you can
find out what cases your MUD uses a lot.  Remember: if
your MUD only does it ten times a day, you don't care
how slow it is :-)  If it does it ten times a second,
you might care.  If it does it ten times per attack,
you have a problem :-P

> One of the possible problems is that if every single
> thing the player 
> does, sends a message and there are lots and lots of
> things listening to 
> these messages it gets cumbersome, at least if the
> whole thing is 
> implemented in LPC, I just thought if there was some
> internal support 
> for such things it might be faster.

  Nope.  The Kernel Library just builds this stuff in
LPC, which is fine because it's still pretty fast. 
You can build it in C if you need to for some reason,
but it's much easier not to.  And chances are good
that this won't be what's bogging your MUD down, so I
wouldn't bother if I were you.


=====
------
noah_gibbs at yahoo.com

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd



More information about the DGD mailing list