[DGD] just out of curiosity

RobF squaretriangle at hotmail.co.uk
Mon Sep 10 13:56:45 CEST 2012


I'm wondering what the state of this driver is.

It is clearly the most technologically accomplished MUD driver out 
there, but I'm wondering if Felix wants to distance it from its roots, 
given that the MUD lib that he was going to code never transpired and 
the feature-set goes far beyond what a MUD would require.

And I even wonder whether he is working on DGD/Hydra under contract. 
Might not be something he is willing or allowed to divulge, but it just 
has me curious that given the decline in popularity of MUDs generally 
and DGD's historical lack of uptake by MUD developers (which may be 
argued as being for the best, as so many MUDs are dime-a-dosen clones of 
one another), and the way he plods on with it for going on two decades.

During this time the lack of accessability as an actual MUD driver 
hasn't improved much except by the contributions of third parties. 
There hasn't been much interest shown in improving the documentation 
(correct me if i'm wrong), leaving the labyrinthian mailing list 
archives as the sole source of understanding the nuances of this 
complicated and unique dialect of LPC, which I don't think is ideal or 
user-friendly even for those technically inclined such as career 
programmers.

'Hydra' is an apt sort of name for it not just for the 
multi-threadedness but the power and potential of the system.  I don't 
know how he has the time as an obvious professional to lend his valuable 
skills to such a project unless he is the client of a high profile firm, 
or something.  Once again, not wishing to pry into what is none of my 
business, but I am curious.

I myself have had a replacement kernel in the back of my head for a 
while, with at least one flagship feature I've not seen in the existing 
one.  I was going to hang onto the idea but I'm not as yet actually 
procuring the result, so by now I figure I may as well share and share 
alike and see if anyone wants to snitch the concept (or tell me it 
sucks, or has already been tried for all that I know and isn't as great 
as I think, not that I'm saying it is...).

The idea being of hiding the distinction between cloneables and 
inheritables.  In the context of that-which-sits-in-the-kernel (let's 
call it the lib), it only sees a single object by a single name, and 
depending on how the object is used it will invoke an operation on an 
internally referenced inheritable or cloneable version of the object. 
The result would be a seamless illusion of their being just one object 
that can be inherited or cloned, and the maintainer of the lib wouldn't 
have to observe or remember the distinction of their being inheritables 
and cloneables.  If needs be I could describe how such a feature would 
be implemented and work but that should probably be enough to figure it out?

The only negative I have to say about the driver is that its developer 
seems to have an odd design philosophy, or at least one that he isn't 
anxious to have the people interested in utilizing the driver (one might 
even say, 'fans' of the driver) understand or appreciate.  Or at least, me.

As just one instance, he nonchalantly told me that there is no way for 
code written within the rules of the dgd-extension system to access 
objects--with no further comment, as if he had no interest in resolving 
this fact--he didn't clarify whether it was impossible to resolve, or 
just challenging for him, or if he just wasn't interested in dealing 
with it regardless.

This, even though this state of affairs leaves the extension system 
outrightly broken almost to the point of uselessness, as we all know 
that the most powerful aspects of DGD lies primarily in the object 
data-type and what can be done when manipulating said object.

This doesn't seem a way to attract people into using your technology, so 
from what I can gather, he doesn't care, because the people trying to 
use this as a MUD driver aren't his target audience anymore.  Maybe a 
mistaken impression, but it's the impression that I get.  It isn't 
helped when Felix also shows no lack of readiness in recommending the 
other 'more dedicated' MUD drivers out there if they don't like the way 
that things are, even though one might want the features that DGD 
uniquely provides.

Not wishing to cause offense, and I hope also that the way I interacted 
in this forum in the past (8 years ago) hasn't left any prejudice on the 
minds of longer-term list-members that might affect how they perceive 
me.  Hoping just to get a clearer picture of things.  I hope my overall 
respect for the work as a technological accomplishment is seen in 
balance with the criticisms that I have, and that my comments will 
elicit some illuminating feedback or constructive dialog.



More information about the DGD mailing list