Phantasmal MUD Lib for DGD

Phantasmal Site > DGD > MudOS vs DGD

MudOS vs DGD

This is taken straight from the DGD mailing list archives. Since DGD continues its relatively rapid pace of development, and MudOS seems to still be languishing, this is all likely to still be accurate. And DGD, if anything, is gaining even further on MudOS. I like to think my own library, Phantasmal, makes a difference in the usual 'no available libraries' argument against DGD, but if you don't like libraries based on the Kernel Library, you won't like Phantasmal.

From: John "West" McKenna
Subject: Re: [DGD]Hello, think you could answer a few questiosn for me? :)
To: DGD Mailing List
Date: Mon, 24 Apr 2000 10:36:28 +0800 (WST)

>    Now for my main question..  What are the main advantages and 
>disadvantages of the MudOS vs. DGD drivers?

The biased answer: DGD is infinitely superior in every way :-)

It's a personal preference thing, I think.  They're both quite capable of
running MUDs.  MudOS does a lot more work in the driver, where DGD leaves
it all for you.  LPC isn't the fastest language in the world, so doing more
work in the driver might be a good idea.  Of course, DGD's precompiling
(compiling LPC to C and linking it into the driver) does very good things
to performance.  Has anyone done any performance comparisions?

The use of 'nil' instead of zero for not-an-object or not-a-string etc
makes a bigger difference than you'd think.

I'm also in love with the object upgrading: unless MudOS has picked up some
new features since I last played with it, you have the destruct-update-
clone cyle every time you make a change to anything.  If you've changed
something fundamental like the user object, you might as well just take the
whole MUD down.  DGD can replace the code of existing (and running) objects
on the fly.  I've written myself a handy little "upgrade" command that
looks for modified files, and automagically recompiles everything that
depends on them.  I find it painful to go back to MudOS development.

Personal preference again: DGD has far fewer built-in functions, and the
ones that are there are very simple.  This means that anything tricky is
done in LPC, and you don't have to go reading driver source to find out
what it does (who trusts documentation?).  More importantly, you can change
it.

DGD doesn't have closures or lambdas or anything like that.  I don't miss
them - I never used them on MudOS (because I'd never found any decent
documentation, or had someone tell me what they're actually for).

I'm not all that keen on DGD's method for adding extension packages.
Patching the driver source just doesn't feel right.  MudOS's "stick the
file in the directory and it will happen" is nice.

DGD doesn't have snoop() or shadow().  As far as I can see, these are
nothing but security holes.  Does anyone know what they're actually good
for?  What possessed whoever was responsible to include them in the first
place?

There's more, but I'm a bit hazy on the details.  DGD supports saving the
entire MUD state to a file, so you can restart as if nothing had happened.
I've never used this.  It also has compile-time and run-time type checking,
which makes debugging that little bit less unpleasant.

Date: Sun, 23 Apr 2000 23:10:21 -0400 (EDT)
From: Stephen Schmidt
To: DGD Mailing List
Subject: Re: [DGD]Hello, think you could answer a few questiosn for me? :)

On Mon, 24 Apr 2000, John West McKenna wrote:
> DGD doesn't have snoop() or shadow().  As far as I can see, these are
> nothing but security holes.  Does anyone know what they're actually good
> for?

If you are actually running a mud with a sizeable number of
players (I adminned one that averaged 60-80 players online
at once, about 300 unique players per day, for a couple years)
then snoop() or something like it is absolutely necessary for
enforcing the rules. Problems with sexual harassment, player
killing, newbie abuse, multiple logins, any situation involving
rules like that are very hard to solve unless you can snoop
and see what the suspect is doing. You should have a general
disclaimer in your login process advising people not to assume
they have more privacy than they actually do. The problem is to
make sure that snoop() is only accessible to those who really
need it, and only when.

Of course, it's not impossible to add a snoop() feature to
your DGD mudlib of choice, though I don't know of any that
come with it unless 2.4.5 does.

I concur that shadow() is not necessary and may not be worth
the risk of having it. It depends on how comfortable you are
with mudlibs that have a separate body object and connection
object, and how willing you are to swap bodies around. If you
have a game design that requires lots of doppleganger-type
behavior, and you don't wanna swap body objects all the time,
then shadow() can be pretty handy. But otherwise it's not
the Right Thing.

> There's more, but I'm a bit hazy on the details.  DGD supports saving the
> entire MUD state to a file, so you can restart as if nothing had happened.

That's my very favorite feature, because it lets you create a
world which can be permanently altered by the players themselves
in a  meaningful way. (You can hack such behavior in under MudOS,
but it's a lot easier under DGD.) The games I'm interested in
creating would use that feature, so I would want DGD for them.
But if that's not your angle, then it may not be so useful.


Stephen Schmidt

It is vain to expect a well-balanced government without a
well-balanced society.
			-- Gideon Welles

Date: Mon, 24 Apr 2000 15:14:48 +0200 (CEST)
From: "Felix A. Croes"
To: DGD Mailing List
Subject: Re: [DGD]Hello, think you could answer a few questiosn for me? :)

BladeDarkmour wrote:

>[...]
>     Now for my main question..  What are the main advantages and 
> disadvantages of the MudOS vs. DGD drivers?   I'd like un-biased responses 
> btw ;)   Allready have DGD setup with a small barebones mudlib, Melville, for 
> piddling around with but haven't yet been able to get MudOS fully setup for 
> some odd reason..  Got the driver setup and installed properly but the mudlib 
> that ships with it is giving me a small fit. *shrugs*  Ah well, I'm sure I 
> can resolve that soon enough.

I wrote DGD, so I won't even keep up a pretense of being unbiased.
I'll just mention two major points:

 - DGD has persistence.  MudOS users claim that persistence is just
   something that you can program yourself in LPC, and they're almost
   correct; if handled in LPC, every object has to make sure that it
   can save and reinitialize itself.  Buggy objects are out of luck.
   The basic functions underlying the saving mechanism in MudOS are
   marred by a number of limitations which further restrict the sort
   of object that can have persistance.
 - DGD is being actively maintained and developed.  MudOS has seen
   no more than a handful of bugfixes since November 1997, out of
   the hundreds of bugs that have been reported, and no new
   development at all.  In practice this means that if you use MudOS,
   you must be prepared to do your own driver hacking.

Regards,
Dworkin

Date: Mon, 24 Apr 2000 17:20:13 +0200 (CEST)
From: "Felix A. Croes"
To: DGD Mailing List
Subject: Re: [DGD]Hello, think you could answer a few questiosn for me? :)

Stephen Schmidt wrote:

> On Sun, 23 Apr 2000, Par Winzell wrote:
> > BladeDarkmour writes:
> > > Aye, [state saving]'s one of the features of DGD that caught my
> > > eye.. Tis a requirement, and I prefer not to have to code support for
> > > it myself.
>  
> > You couldn't.
>
> Actually, even under MudOS, you can, because of the save_object()
> feature. The cost is that you can't use clones anymore; each object
> needs to have its own save file, so it has to have its own code
> file. (And, in fact, there's ways around that too, though not
> good ones.) You have to do some additional work to preserve
> environment information, and so forth, but it's doable.
>
> But it's way too hard when DGD is available with state saves
> as a driver feature.

Mimicing DGD's persistence (or, for that matter, any other persistent
mud server's persistence; it is only MudOS people who define the term
so sloppily) is not just hard in MudOS, it really is impossible.

The limitations you mention are limitations of current implementations
in the Nightmare and Lima mudlibs.  These are tradeoffs for simplicity
and have little to do with actual MudOS limitations.  There are many
more, including: datastructures shared between objects are not saved
as shared, self-referential datastructures cannot be saved at all,
neither can object references, etc.

The show-stopper with regard to persistence in MudOS is that it is
impossible to query the full state of any given object from LPC.

Regards,
Dworkin



Date: Thu, 11 May 2000 02:57:26 +0200 (CEST)
From: "Felix A. Croes"
To: DGD Mailing List
Subject: Re: [DGD]statedumping

Stephen Schmidt wrote:

> On Wed, 10 May 2000, E. Harte wrote:
> > I'd say that DGD makes it very easy for a
> > developer to track objects and make sure the basis is airtight when it
> > comes to leaking objects.
>
> Is it easier in DGD than in, say, MudOS? After all, you can
> use simul_efuns() to override load_object() and clone_object()
> in MudOS if you want to implement such a thing. I've never
> tried it, so maybe there's something I haven't observed.

Definitely easier.  The simul_efun feature can replace functions in
the auto object, but not variables in the auto object -- which make
per-wizard linked lists of objects possible.


>[...]
> > In a decent mudlib you'd have limitations in place that
> > avoid an object going berzerk and creating clones or adding call_outs
> > until the mud crashes.
>
> Most publically available mudlibs don't live up to this
> standard, unfortunately, though I agree that it would be
> good if they did.

If you base your mudlib on the kernel lib, such resource control
is automatic.  You can even define your own resources.  You could,
for instance, create a money resource and use it to impose limits
on how much money a wizard can give out.

Regards,
Dworkin


Date: Wed Aug  1 08:48:00 2001
Subject: [DGD] MudOS or DGD

On Wed, 1 Aug 2001, Stephen Schmidt wrote:
> On Wed, 1 Aug 2001, Gary wrote:
> > From: "Sergey S. Koval"

> > > 2. Is it possible to add own "plugin" efuns without altering driver code ?
> >
> >   DGD uses kfuns, which I think are very similar to efuns. Checkout the
> > kernel docs in the documents directory.
>
> A DGD kfun is probably more similar to a MudOS simul_efun than
> to an efun, although the analogy's not perfect in either case.

Oops! My mistake. A DGD kfun is basically the same as a MudOS efun.
It's the auto functions that are similar to, but not identical to,
simul_efuns. Sorry for the confusion.

Steve



From DGD Mailing List  Wed Jul 30 21:19:01 2003
From: DGD Mailing List (Stephen Schmidt)
Date: Wed Jul 30 21:19:01 2003
Subject: Re[2]: [DGD] test

On Thu, 31 Jul 2003, Lucifer wrote:
> Eh... since you ask me what i need and i am quite new to dgd... could
> you tell me about the grammar differences between dgd and 'traditional
> lpc' (I only have some experience with MudOS before)?

I was a MudOS hacker for about five years before switching to DGD.

I never had any trouble moving between drivers. DGD has rather
fewer (I'm probably mixing MudOS and DGD terminology here, so
forgive me) driver-supplied functions than MudOS, but most of
the critical ones are the same, and many of the ones not in
DGD will be provided, sometimes under the same name, by the
mudlib you use. There's a few changes, of course, but nothing
difficult to get used to.

Much bigger changes will come when you stop using whatever
MudOS mudlib you're used to (probably either TMI-2 or
Nightmare, which are fairly similar) and start using a
DGD mudlib. One option is the 2.4.5-simulated mudlib,
which I would recommend not using. There used to be basically
two other choices, the kernal mudlib and the Melville mudlib.
The kernel mudlib is very powerful and lets you take advantage
of all current DGD features, but is complicated and a major
change from MudOS libs. Melville is rather similar to MudOS
mudlibs and will be a familiar environment, but it's rather
old (written 1994, revised last 1998) and doesn't let you do
many of the cool things the driver permits.

Since I stopped working regularly on DGD, at least one or
two more mudlibs have come out, but I will let others who
know them better describe them....

Steve


Aha! Advancing on me only brings you closer to the cold wrath
that is my Spork!
				- BK


From DGD Mailing List  Thu Jul 31 05:58:01 2003
From: DGD Mailing List (Christian McCarron)
Date: Thu Jul 31 05:58:01 2003
Subject: [DGD] test

On Wed, Jul 30, 2003 at 10:18:06PM -0400, Stephen Schmidt wrote:
> On Thu, 31 Jul 2003, Lucifer wrote:
> > Eh... since you ask me what i need and i am quite new to dgd... could
> > you tell me about the grammar differences between dgd and 'traditional
> > lpc' (I only have some experience with MudOS before)?
> 
> I was a MudOS hacker for about five years before switching to DGD.
> 
> I never had any trouble moving between drivers. DGD has rather
> fewer (I'm probably mixing MudOS and DGD terminology here, so
> forgive me) driver-supplied functions than MudOS, but most of
> the critical ones are the same, and many of the ones not in
> DGD will be provided, sometimes under the same name, by the
> mudlib you use. There's a few changes, of course, but nothing
> difficult to get used to.

The thing thats causing me problems looking at moving from MudOS to
DGD (something I'd love to do on many, many levels) is the function
pointers. We use anonymous functions a lot, and we've been quite
creative in some of the uses we've put them to. Even basic functionality
like map(arr,(: code :)) seems to have no easy fix without turning the
code into a whole new function and calling it. Other things like macros
which auto-construct arbitarily layered function pointers for dynamic
descriptions etc really look like they'd need a total rewrite, at the core
and in every single room that uses them.

Since the mud I run is in its 11th year, as you can imagine we have an
awfully large number of rooms!

I understand that Dworkin doesn't like fp's/closures etc, but is there any
way these can be done via a package? Whether or not fp's are the best way to
do this kind of thing (although we have found them incredibly useful), some
way to include the syntax in the driver as an optional package would allow
a lot of MudOS libs to move to DGD with far more ease. Given that MudOS dev
is more or less dead, this could inject a lot of new blood, and a lot of
experienced developers into the DGD community.

Larnen


From DGD Mailing List  Thu Jul 31 09:33:01 2003
From: DGD Mailing List (Par Winzell)
Date: Thu Jul 31 09:33:01 2003
Subject: [DGD] test

>>I understand that Dworkin doesn't like fp's/closures etc, but is there any
>>way these can be done via a package? Whether or not fp's are the best way to
>>do this kind of thing (although we have found them incredibly useful), some
>>way to include the syntax in the driver as an optional package would allow
>>a lot of MudOS libs to move to DGD with far more ease. Given that MudOS dev
>>is more or less dead, this could inject a lot of new blood, and a lot of
>>experienced developers into the DGD community.
> 
> Lee Salzman wrote a patch to add function
> pointers to DGD, available at the URL
> 
>     http://www.lvdi.net/~lee.salzman/dgd-mod.diff.gz
> 
> (I haven't checked to see if this still works).  It is only suited for
> DGD 1.2 and perhaps 1.2pX, not later versions.

This can also be done at the LPC level better than ever before:
  * The combination of LWO's and compilation-from-source makes it very 
easy to do things like comparer = Lambda("a", "b", "return a < b;"); arr 
= sort_array(arr, comparer);
  * Long ago, Dworkin posted a full grammar for the LPC language, 
suitable for use in parse_string(). It has a few errors in it, and it 
needs to be updated with language changes since then, but it basically 
works, and parsing LPC is quite fast. We use it at Skotos to parse a 
mutation of LPC. If all compilation went through such a layer first, you 
might be able to add lambda expressions and such at the syntactic level.

Zell

From DGD Mailing List  Thu Jul 31 14:52:01 2003
From: DGD Mailing List (Noah Gibbs)
Date: Thu Jul 31 14:52:01 2003
Subject: [DGD] test

  Somebody already mentioned the excellent possibility
of using compilation of strings, which would probably
be the best way.
  But you could also, for function pointers, use a
two-element array of strings -- the object name and
the function name.  It'd be easy to make them
dynamically, and easy assign them.  Calling them would
just require you to use call_other.