Re: [LONG] Spell parser

From: Brian (
Date: 09/09/02

Artovil wrote:
> > Write a simple script in an editor that is parsed on cast; for an affect:

Thomas Arp wrote:
> This would be slow. Having to run through a script on each cast,
> before determining output, affections etc. would slow your mud
> down considerably.


> It _will_ be slower. It _will_ eat your memory. If you make it right,
> it will also be easier to work with, and to expand without recompiling.

I doubt redoing large portions of the spells in Circle would cause a
*noticeable* slowdown.  I'm sure it would be significantly slower and
more memory intensive, but I think even the most meager 486s wouldn't
notice.  Granted, I don't know how efficient mobprogs or DGScripts are,
never having worked with them.

I hate to bring up another MUD family for comparison, but it is
applicable in this case.

I've coded somewhat extensively on an LP MUD, and for those of you that
don't know, an LP MUD is broken into the driver and the mudlib.  The
driver provides basic functionality, network handling, etc. and is
written in C.  Everything else is written in an interpreted C-like
language, LPC.  There are details I'm leaving out, but I'm trying to say

The point is that LP MUDs run almost entirely on an interpreted
scripting language such as the one proposed, and I have yet to see
noticeable lag or a large speed difference in anything except for disk
intensive operations -- quite rare in a MUD -- but recently noticeable
in a grep command I rewrote because the old one had issues.  MUDs simply
don't use that much processor power or memory unless really heavily
loaded with players (or really poorly coded).

Now if we wanted to go on about truly noticeable CircleMUD lag, we could
go on about the lack of a non-blocking DNS lookup in the *stock*
distribution.  But there I go getting tangential.

   | FAQ: |
   | Archives: |
   | Newbie List:   |

This archive was generated by hypermail 2b30 : 06/25/03 PDT