[MUD-Dev] Object and class heirarchies -- are they really nec essary?

[Koster]

> -----Original Message-----
> From: Par Winzell [mailto:zell at alyx.com]
> Sent: Tuesday, March 21, 2000 5:00 PM
> To: mud-dev at kanga.nu
> Subject: Re: [MUD-Dev] Object and class heirarchies -- are they really
> necessary?
> 
> 
> J C Lawrence writes:

>  > Christopher commented that they do the same things 
> (assembling their
>  > super-class from more malleable single-purpose pieces) -- except
>  > that they do it conciously and with intent aforethought.

> My favourite benefit of this approach is the same one that e.g. Diku
> has over most LPMuds... that you nail down in the implementation of
> the single physical class the entireity of the feature set... and as
> a consequence, all physical objects are guaranteed to respond sanely
> to a known set of actions.

This is what I referred to as the great strength of Dikus--they are
template-based muds. The template constrains, but only insofar as the data
set that the template provides. If you can expand the template and supply
default values to objects that have not been manually updated with new data,
then your constraints pretty much go away without having to subclass new
object types, etc.

> So though in theory, with competent and _disciplined_ developers, the
> LPMud can be everything a Diku can and then some, in practice there's
> no question which code base I prefer to be a player in. Since Skotos
> uses DGD, an LP driver, we must attempt to conjure up this discipline
> largely through our world implementation (and developer interface).

cf my LP vs Diku posting from ages ago, it's in the archives and also on my
website. Key point is near the end, and is equally applicable to your
approach: "The name of the game in Dikus really has to be making the
templates they load more flexible"... in other words, for your approach,
providing an architecture to your superclass so that your methods can easily
be added to, expanded on, and customized in greater detail...

http://www.legendmud.org/raph/gaming/index.html

start quote--->
I'd like to expand a little on the Diku side to [Tim Hollebeek's] excellent
reply on the differences between Diku-derived muds and LPMuds. 

Whereas the great strength of LPMuds is the fact that they are so flexible
and programmable, the great strngth of Diku derived muds is that they are
not. The more complex the system required to build or to get the game
running, the less likely that said system will ever be successfully set up.
This is why the template approach of Diku style muds proved so popular. They
are very easy to set up, al the databases even among the different code
bases are remarkably similar (i.e. converting areas between stock Diku,
Merc, Circle, etc, is remarkably easy, if indeed any conversion is
necessary) and hence large muds can be opened from scratch by spending a few
hours with FTP. 

This is also the great weakness of Diku of course--they are
fill-in-the-blank muds. 

LPs have the opposite problem. To make a unique LP implies a certain level
of ability at coding in LPC, which is, to be honest, as rare as the certain
amount of ability required to code in C on a Diku. The result is that momst
LPMuds take a standard mudlib off the shelf, and run with it, in effect
ACTING as template-based muds even though they have a wonderful and powerful
architecture underneath. 

I don't think there is any question that LP is far more powerful than
Diku-derived code bases. You could write a fully-Diku-compatible mud in LP,
and make it better. But Dikus will not go away because they are much, much,
much easier to use for the most part. (Yes, a well-designed mudlib can be
easier to use as a Diku, I know... my point is that the work required to get
it to that point is not generally done). 

The trend among dikus that Tim mentioned, regarding adding scripting and so
on, isn't exactly new, of course, but it has taken a surprising amount of
time to catch on. But scripting alone isn't the real design issue. The name
of the game in Dikus really has to be making the templates they load more
flexible yet backwards compatible. Adding new sections to the template that
are optional but permit greater detailing, customization, etc. Permitting
each builder to find their own level... 

LP is a better system. But I prefer to do my work on Dikus. :)
<---end quote

-Raph



_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev