Re: MOBProg patches (fwd)
Date: 06/15/94

In message <>  you wrote:
>While I will agree that the speed difference is virtually non-existant, I
>do disagree with the relavent part.  While it is true that every ten
>seconds a standard CircleMUD will go through every mob, this does not have
>to be the case.  It is extremely simple to set up a simple queue to
>handle aggressive mobs, mobs that take items and mobs that move, while
>leaving the rest alone.  I've used this technique to handle all of our
>mobile and object needs (Circle also hits every item every  tick, as
>well as an attempt to heal each mob every tick)

Granted, this is simple, and probably should be done at some point.

>Looking at the MOBProgs code, it looks just like a shell script.  It seems
>to me that people could learn C almost as easily as the script language.

You'd actually be surprised.  MUSH code (the interpreted stuff I refered
to in my previous note) also looks a LOT like shell script, and you get
people who are NOT computer experts crafting fairly complex objects in it.
Now granted, it does have more capabilities than the current set of MOBprog
functionality, but the mobprog stuff can be extended as well (for instance
I would like a way for the mobprog script to tell if the mob can see a
player, or even better if the player is vis/invis, and I might add it myself)

The big benefit to something like MOBProgs over C is that you don't need to
recompile the server every time you want to tinker with something, all you
need to do is reload the world (shutdown and restart)

>With speed, no, but due to the simplicity of the script language, it
>may be evident if extensive and complicated special procedures are used.
>Don't get me wrong, I think this is a nice feature that could be added
>to the code.  But for what I usually end up designing, I think it's
>too simplistic.

MOBprogs aren't meant to replace special proceedures completely,
what I feel they should be used for is to replace very simple and common
special proceedures (like for instance the fido spec_proc for devouring
corpses) as well as making mobiles a bit more alive, or setting up a
one-time quest (you write the mobprog, load the db, when the quest is
done, remove the mob-prog, and reboot the game)

I'm competant enough to craft fairly complex and elegant C code to do
whatever I want.  I would still use mobprogs for simple things that should
be no-brainers.  I would then write more complex and interesting routines
in C.  Mobprogs allow area designers to make them interesting without them
needing to learn C and without me needing to debug their code to make sure
it doesn't crash and burn the game (a serious problem with Spec_procs) or
even worse, having them ask me to make them a spec_proc so that their
dog can bark or growl at people when they enter the room.


This archive was generated by hypermail 2b30 : 12/07/00 PST